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1. Introduction 


The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in 
[RFC6388] allows traffic to transmit from root to several leaf nodes, 
and multipoint-to-multipoint (MP2MP) LSP allows traffic from every 
node to transmit to every other node. This document introduces a hub 
and spoke multipoint (HSMP) LSP, which has one root node and one or 
more leaf nodes. An HSMP LSP allows traffic from root to leaf 
through downstream LSP and also leaf to root along the upstream LSP. 
That means traffic entering the HSMP LSP at the root node travels 
along the downstream LSP, exactly as if it were traveling along a 
P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes 
travels along the upstream LSP toward only the root node. The 
upstream LSP should be thought of as a unicast LSP to the root node, 
except that it follows the reverse direction of the downstream LSP, 
rather than the unicast path based on the routing protocol. The 
combination of upstream LSPs initiated from all leaf nodes forms a 
multipoint-to-point LSP. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document uses the following terms and acronyms: 


mLDP: Multipoint extensions for Label Distribution Protocol (LDP) 
defined in [RFC6388]. 


P2MP LSP: point-to-multipoint Label Switched Path. An LSP that 
has one Ingress Label Switching Router (LSR) and one or more 
Egress LSRs. 


MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP 
that connects a set of nodes, such that traffic sent by any node 
in the LSP is delivered to all others. 


HSMP LSP: hub and spoke multipoint Label Switched Path. An LSP 
that has one root node and one or more leaf nodes, allows traffic 
from the root to all leaf nodes along the downstream P2MP LSP and 
also leaf to root node along the upstream unicast LSP. 


FEC: Forwarding Equivalence Class 
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3. Setting Up HSMP LSP with LDP 


An HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the 
difference being that, when the leaf LSRs send traffic on the LSP, 
the traffic is first delivered only to the root node and follows the 


upstream path from the leaf node to the root node. The root node 
then distributes the traffic on the P2MP tree to all of the leaf 
nodes. 


An HSMP LSP consists of a downstream path and upstream path. The 
downstream path is the same as P2MP LSP, while the upstream path is 
only from leaf to root node, without communication between the leaf 
nodes themselves. The transmission of packets from the root node of 
an HSMP LSP to the receivers (the leaf nodes) is identical to that of 
a P2MP LSP. Traffic from a leaf node to the root follows the 
upstream path that is the reverse of the path from the root to the 
leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch 
toward other leaf nodes, but it is sent direct to the root where it 
is placed on the P2MP path and distributed to all leaf nodes 
including the original sender. 


To set up the upstream path of an HSMP LSP, ordered mode MUST be 
used. Ordered mode can guarantee that a leaf will start sending 
packets to the root immediately after the upstream path is installed, 
without being dropped due to an incomplete LSP. 


3.1. Support for HSMP LSP Setup with LDP 


An HSMP LSP requires the LDP capabilities [RFC5561] for nodes to 
indicate that they support setup of HSMP LSPs. An implementation 
supporting the HSMP LSP procedures specified in this document MUST 
implement the procedures for Capability Parameters in Initialization 
messages. Advertisement of the HSMP LSP Capability indicates support 
of the procedures for HSMP LSP setup. 


A new Capability Parameter TLV is defined, the HSMP LSP Capability 
Parameter. Below is the format of the HSMP LSP Capability Parameter. 


0 1 2 3 
01234567890123456789012345678901 
—R———c—.-—.-—-—-—R-—R—R—R-—R—R—R— RM BMBMB—MÁÁBMÁBMÁBMÁÁBMÁBBAÓ BÓ —t -t 
|u|F| HSMP LSP Cap (0x0902) | Length 
d—R————.—.-—-—-—R-—R—R—R—R-—R—R—R— RR R—R—R—————-—.-.-t-t-t-t 
|s| Reserved | 

+-+-+-+-+-+-+-+-+ 


Figure 1: HSMP LSP Capability Parameter Encoding 
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U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST 
be 1. The unknown TLV MUST be silently ignored and the rest 
of the message processed as if the unknown TLV did not exist. 


F-bit: Forward unknown TLV bit, as described in [RFC5036]. The 
value of this bit MUST be 0 since a Capability Parameter TLV 
is sent only in Initialization and Capability messages, which 
are not forwarded. 


Length: SHOULD be 1. 

S-bit: As defined in Section 3 of [RFC5561]. 
Reserved: As defined in Section 3 of [RFC5561]. 
HSMP LSP Capability Parameter type:  0x0902. 


If the peer has not advertised the corresponding capability, then 
label messages using the HSMP Forwarding Equivalence Class (FEC) 
Element SHOULD NOT be sent to the peer (as described in Section 2.1 
of [RFC6388]). Since ordered mode is applied for HSMP LSP signaling, 
the label message break would ensure that the initiating leaf node is 
unable to establish the upstream path to root node. 


3.2. HSMP FEC Elements 


We define two new protocol entities: the HSMP Downstream FEC Element 
and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC 
Elements, the HSMP FEC Element MUST be the only FEC Element in the 
FEC TLV. The structure, encoding, and error handling for the HSMP- 
downstream FEC Element and HSMP-upstream FEC Element are the same as 
for the P2MP FEC Element described in Section 2.2 of [RFC6388]. The 
difference is that two additional new FEC types are defined: HSMP- 
downstream FEC (10) and HSMP-upstream FEC (9). 


3.3. Using the HSMP FEC Elements 


The entries in the list below describe the processing of the HSMP FEC 
Elements. Additionally, the entries defined in Section 3.3 of 
[RFC6388] are also reused in the following sections. 


I HSMP downstream LSP «X, Y» (or simply downstream «X, Y»): an 
HSMP LSP downstream path with root node address X and opaque 
value Y. 
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pas HSMP upstream LSP «X, Y» (or simply upstream «X, Y»): an HSMP 
LSP upstream path for root node address X and opaque value Y 
that will be used by any downstream node to send traffic 
upstream to root node. 


3s HSMP-downstream FEC Element «X, Y»: a FEC Element with root node 
address X and opaque value Y used for a downstream HSMP LSP. 


4. HSMP-upstream FEC Element «X, Y»: a FEC Element with root node 
address X and opaque value Y used for an upstream HSMP LSP. 


5; HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a 
single HSMP-downstream FEC Element <X, Y> and label TLV with 
label L. Label L MUST be allocated from the per-platform label 
space of the LSR sending the Label Mapping Message. 


6. HSMP-U Label Mapping «X, Y, Lu»: A Label Mapping message with a 
single HSMP upstream FEC Element «X, Y» and label TLV with label 
Lu. Label Lu MUST be allocated from the per-platform label 
space of the LSR sending the Label Mapping Message. 


1 HSMP-D Label Withdraw «X, Y, L>: a Label Withdraw message with a 
FEC TLV with a single HSMP-downstream FEC Element «X, Y» and 
label TLV with label L. 


8. HSMP-U Label Withdraw «X, Y, Lu»: a Label Withdraw message with 
a FEC TLV with a single HSMP-upstream FEC Element «X, Y» and 
label TLV with label Lu. 


9. HSMP-D Label Release <X, Y, L>: a Label Release message with a 
FEC TLV with a single HSMP-downstream FEC Element <X, Y> and 
Label TLV with label L. 


10. HSMP-U Label Release «X, Y, Lu»: a Label Release message with a 
FEC TLV with a single HSMP-upstream FEC Element «X, Y» and label 
TLV with label Lu. 


3.4. HSMP LSP Label Map 


This section specifies the procedures for originating HSMP Label 
Mapping messages and processing received HSMP Label Mapping messages 
for a particular HSMP LSP. The procedure of a downstream HSMP LSP is 
Similar to that of a downstream MP2MP LSP described in [RFC6388]. 
When LDP operates in Ordered Label Distribution Control mode 
[RFC5036], the upstream LSP will be set up by sending an HSMP LSP LDP 
Label Mapping message with a label that is allocated by the upstream 
LSR to its downstream LSR hop-by-hop from root to leaf node, 
installing the upstream forwarding table by every node along the LSP. 
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The detailed procedure of setting up upstream HSMP LSP is different 
than that of upstream MP2MP LSP, and it is specified in the remainder 
of this section. 


All labels discussed here are downstream-assigned [RFC5332] except 
those that are assigned using the procedures described in Section 4. 


Determining the upstream LSR for the HSMP LSP «X, Y» follows the 
procedure for a P2MP LSP described in Section 2.4.1.1 of [RFC6388]. 
That is, a node Z that wants to join an HSMP LSP «X, Y» determines 
the LDP peer U that is Z's next hop on the best path from Z to the 
root node X. If there are multiple upstream LSRs, a local algorithm 
should be applied to ensure that there is exactly one upstream LSR 
for a particular LSP. 


To determine one's HSMP downstream LSR, an upstream LDP peer that 
receives a Label Mapping with the HSMP-downstream FEC Element from an 
LDP peer D will treat D as HSMP downstream LDP peer. 


3.4.1. HSMP LSP Leaf Node Operation 


The leaf node operation is much the same as the operation of MP2MP 
LSP defined in Section 3.3.1.4 of [RFC6388]. The only difference is 
the FEC elements as specified below. 


A leaf node Z of an HSMP LSP «X, Y» determines its upstream LSR U for 
«X, Y» as per Section 3.3, allocates a label L, and sends an HSMP-D 
Label Mapping «X, Y, L> to U. Leaf node Z expects an HSMP-U Label 
Mapping «X, Y, Lu» from node U and checks whether it already has 
forwarding state for upstream «X, Y». If not, Z creates forwarding 
state to push label Lu onto the traffic that Z wants to forward over 
the HSMP LSP. How it determines what traffic to forward on this HSMP 
LSP is outside the scope of this document. 


3.4.2.  HSMP LSP Transit Node Operation 


The procedure for processing an HSMP-D Label Mapping message is much 
the same as that for an MP2MP-D Label Mapping message defined in 
Section 3.3.1.5 of [RFC6388]. The processing of an HSMP-U Label 
Mapping message is different from that of an MP2MP-U Label Mapping 
message as specified below. 


Suppose node Z receives an HSMP-D Label Mapping «X, Y, L» from LSR D. 
Z checks whether it has forwarding state for downstream «X, Y». If 
not, Z determines its upstream LSR U for «X, Y> as per Section 3.3. 
Using this Label Mapping to update the label forwarding table MUST 
NOT be done as long as LSR D is equal to LSR U. If LSR U is 
different from LSR D, Z will allocate a label L' and install 
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downstream forwarding state to swap label L’ with label L over 
interface I associated with LSR D and send an HSMP-D Label Mapping 
«X, Y, L'» to U. Interface I is determined via the procedures in 
Section 3.7. 


If Z already has forwarding state for downstream «X, Y», all that Z 
needs to do in this case is check that LSR D is not equal to the 
upstream LSR of «X, Y» and update its forwarding state. Assuming its 
old forwarding state was L'-» («I1, L1» «I2, L2» ..., «In, Ln»), its 
new forwarding state becomes L'-» [(«I1, L1» «I2, L2» ..., «In, Ln», 
<I, L>}. If the LSR D is equal to the installed upstream LSR, the 
Label Mapping from LSR D MUST be retained and MUST NOT update the 
label forwarding table. 


Node Z checks if the upstream LSR U already has assigned a label Lu 
to upstream «X, Y». If not, transit node Z waits until it receives 
an HSMP-U Label Mapping «X, Y, Lu» from LSR U. Once the HSMP-U Label 
Mapping is received from LSR U, node Z checks whether it already has 
forwarding state upstream «X, Y» with incoming label Lu' and outgoing 
label Lu. If it does not, it allocates a label Lu' and creates a new 
label swap for Lu' with Label Lu over interface Iu. Interface Iu is 
determined via the procedures in Section 3.7. Node Z determines the 
downstream HSMP LSR as per Section 3.4 and sends an HSMP-U Label 
Mapping «X, Y, Lu'» to node D. 


Since a packet from any downstream node is forwarded only to the 
upstream node, the same label (representing the upstream path) SHOULD 
be distributed to all downstream nodes. This differs from the 
procedures for MP2MP LSPs [RFC6388], where a distinct label must be 
distributed to each downstream node. The forwarding state upstream 
«X, Y» on node Z will be like this: {<Lu’>, «Iu Lu»). Iu means the 
upstream interface over which Z receives HSMP-U Label Map «X, Y, Lu» 
from LSR U. Packets from any downstream interface over which Z sends 
HSMP-U Label Map «X, Y, Lu'» with label Lu' will be forwarded to Iu 
with label Lu' swapped to Lu. 


3.4.3. HSMP LSP Root Node Operation 


The procedure for an HSMP-D Label Mapping message is much the same as 
processing an MP2MP-D Label Mapping message defined in 

Section 3.3.1.6 of [RFC6388]. The processing of an HSMP-U Label 
Mapping message is different from that of an MP2MP-U Label Mapping 
message as specified below. 


Suppose the root node Z receives an HSMP-D Label Mapping «X, Y, L> 
from node D. Z checks whether it already has forwarding state for 
downstream «X, Y». If not, Z creates downstream forwarding state and 
installs an outgoing label L over interface I. Interface I is 
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determined via the procedures in Section 3.7. If Z already has 
forwarding state for downstream <X, Y>, then Z will add label L over 
interface I to the existing state. 


Node Z checks if it has forwarding state for upstream «X, Y». If 
not, Z creates a forwarding state for incoming label Lu' that 
indicates that Z is the HSMP LSP egress Label Edge Router (LER). For 
example, the forwarding state might specify that the label stack is 
popped and the packet passed to some specific application. Node Z 
determines the downstream HSMP LSR as per Section 3.3 and sends an 
HSMP-U Label Map «X, Y, Lu'» to node D. 


Since Z is the root of the tree, Z will not send an HSMP-D Label Map 
and will not receive an HSMP-U Label Mapping. 


The root node could also be a leaf node, and it is able to determine 
what traffic to forward on this HSMP LSP; that determination is 
outside the scope of this document. 


3.5. HSMP LSP Label Withdraw 
3.5.1. HSMP Leaf Operation 


If a leaf node Z discovers that it has no need to be an Egress LSR 
for that LSP (by means outside the scope of this document), then it 
SHOULD send an HSMP-D Label Withdraw «X, Y, L> to its upstream LSR U 
for «X, Y», where L is the label it had previously advertised to U 
for «X, Y». Leaf node Z will also send an unsolicited HSMP-U Label 
Release «X, Y, Lu» to U to indicate that the upstream path is no 
longer used and that label Lu can be removed. 


Leaf node Z expects the upstream router U to respond by sending a 
downstream Label Release for L. 


3.5.2. HSMP Transit Node Operation 


If a transit node Z receives an HSMP-D Label Withdraw message 

«X, Y, L» from node D, it deletes label L from its forwarding state 
downstream «X, Y». Node Z sends an HSMP-D Label Release message with 
label L to D. There is no need to send an HSMP-U Label Withdraw «X, 
Y, Lu» to D because node D already removed Lu and sent a label 
release for Lu to Z. 


If deleting L from Z's forwarding state for downstream «X, Y» results 
in no state remaining for «X, Y», then Z propagates the HSMP-D Label 
Withdraw «X, Y, L> to its upstream node U for «X, Y». Z should also 
check if there are any incoming interfaces in forwarding state 
upstream «X, Y». If all downstream nodes are released and there is 
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no incoming interface, Z should delete the forwarding state upstream 
«X, Y» and send an HSMP-U Label Release message to its upstream node. 
Otherwise, no HSMP-U Label Release message will be sent to the 
upstream node. 


3.5.3. HSMP Root Node Operation 


When the root node of an HSMP LSP receives an HSMP-D Label Withdraw 
message and an HSMP-U Label Release message, the procedure is the 
same as that for transit nodes, except that the root node will not 
propagate the Label Withdraw and Label Release upstream (as it has no 
upstream). 


3.6. HSMP LSP Upstream LSR Change 


The procedure for changing the upstream LSR is the same as defined in 
Section 2.4.3 of [RFC6388], only with different processing of the FEC 
Element. 


When the upstream LSR changes from U to U', node Z should set up the 
HSMP LSP «X, Y» to U' by applying the procedures in Section 3.4. Z 

will also remove the HSMP LSP «X, Y» to U by applying the procedure 

in Section 3.5. 


To set up an HSMP LSP to U' before/after removing the HSMP LSP to U 
is a local matter. The recommended default behavior is to remove 
before adding. 


3.7. Determining Forwarding Interface 


The upstream and downstream LSPs can be co-routed by applying the 
procedures below. Both LSR U and LSR D would ensure that the same 
interface sends traffic by applying some procedures. For a network 
with symmetric IGP cost configuration, the following procedure MAY be 
used. To determine the downstream interface, LSR U MUST do a lookup 
in the unicast routing table to find the best interface and next hop 


to reach LSR D. If the next hop and interface are also advertised by 
LSR D via the LDP session, it should be used to transmit the packet 
to LSR D. The mechanism to determine the upstream interface is the 


same as that used to determine the downstream interface except the 
roles of LSR U and LSR D are switched. If symmetric IGP cost could 
not be ensured, static route configuration on LSR U and D could also 
be a way to ensure a co-routed path. 


If a co-routed path is not required for the HSMP LSP, the procedure 
defined in Section 2.4.1.2 of [RFC6388] could be applied. LSR U is 
free to transmit the packet on any of the interfaces to LSR D. The 
algorithm it uses to choose a particular interface is a local matter. 
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The mechanism to determine the upstream interface is the same as that 
used to determine the downstream interface. 


4. HSMP LSP on a LAN 


The procedure to process the downstream HSMP LSP on a LAN is much the 
same as for a downstream MP2MP LSP as described in Section 6.1.1 of 
[RFC6388]. 


When establishing the downstream path of an HSMP LSP, as defined in 
[RFC6389], a Label Request message for an LSP label is sent to the 
upstream LSR. The upstream LSR should send a Label Mapping message 
that contains the LSP label for the downstream HSMP FEC and the 
upstream LSR context label defined in [RFC5331]. When the LSR 
forwards a packet downstream on one of those LSPs, the packet’s top 
label must be the "upstream LSR context label" and the packet’s 
second label is the "LSP label". The HSMP downstream path will be 
installed in the context-specific forwarding table corresponding to 
the upstream LSR label. Packets sent by the upstream LSR can be 
forwarded downstream using this forwarding state based on a two-label 
lookup. 


The upstream path of an HSMP LSP on a LAN is the same as the one on 
other kinds of links. That is, the upstream LSR must send a Label 
Mapping message that contains the LSP label for the upstream HSMP FEC 
to the downstream node. Packets traveling upstream need to be 
forwarded in the direction of the root by using the label allocated 
for the upstream HSMP FEC. 


5. Redundancy Considerations 


In some scenarios, it is necessary to provide two root nodes for 
redundancy purposes. One way to implement this is to use two 
independent HSMP LSPs acting as active and standby. At a given time, 
only one HSMP LSP will be active; the other will be standby. After 
detecting the failure of the active HSMP LSP, the root and leaf nodes 
will switch the traffic to the standby HSMP LSP, which takes on the 
role as active HSMP LSP. The details of the redundancy mechanism are 
out of the scope of this document. 


6. Failure Detection of HSMP LSP 


The idea of LSP ping for HSMP LSPs could be expressed as an intention 
to test the LSP Ping Echo Request packets that enter at the root 
along a particular downstream path of HSMP LSP and that end their 
MPLS path on the leaf. The leaf node then sends the LSP Ping Echo 
Reply along the upstream path of HSMP LSP, and it ends on the root 
that is the (intended) root node. 


Jin, et al. Standards Track [Page 11] 


RFC 7140 LDP Extensions for HSMP LSP March 2014 


New sub-TLVs have been assigned by IANA in Target FEC Stack TLV and 
Reverse-path Target FEC Stack TLV to define the corresponding HSMP- 
downstream FEC type and HSMP-upstream FEC type. In order to ensure 
that the leaf node sends the LSP Ping Echo Reply along the HSMP 
upstream path, the R flag (Validate Reverse Path) in the Global Flags 
field defined in [RFC6426] is reused here. 


The node-processing mechanism of LSP Ping Echo Request and Echo Reply 
for the HSMP LSP is inherited from [RFC6425] and Section 3.4 of 
[RFC6426], except for the following: 


1. The root node sending the LSP Ping Echo Request message for the 
HSMP LSP MUST attach the Target FEC Stack TLV with the HSMP- 
downstream FEC type, and set the R flag to '1' in the Global 
Flags field. 


2. When the leaf node receives the LSP Ping Echo Request, it MUST 
send the LSP Ping Echo Reply to the associated HSMP upstream 
path. The Reverse-path Target FEC Stack TLV attached by the leaf 
node in the Echo Reply message SHOULD contain the sub-TLV of the 
associated HSMP-upstream FEC. 


7. Security Considerations 


The same security considerations apply as for the MP2MP LSP described 
in [RFC6388] and [RFC6425]. 


Although this document introduces new FEC Elements and corresponding 
procedures, the protocol does not bring any new security issues 
beyond those in [RFC6388] and [RFC6425]. 

8. IANA Considerations 

8.1. New LDP FEC Element Types 
Two new LDP FEC Element types have been allocated from the "Label 
Distribution Protocol (LDP) Parameters" registry, under "Forwarding 
Equivalence Class (FEC) Type Name Space": 
1. the HSMP-upstream FEC type - 9 
2. the HSMP-downstream FEC type - 10 


The values have been allocated from the "IETF Consensus" [RFC5226] 
range (0-127). 
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8.2. HSMP LSP Capability TLV 
One new code point has been allocated for the HSMP LSP capability TLV 
from "Label Distribution Protocol (LDP) Parameters" registry, under 
"TLV Type Name Space": 
HSMP LSP Capability Parameter - 0x0902 


The value has been allocated from the"IETF Consensus" range 
(0x0901-Ox3DFF). 


8.3. New Sub-TLVs for the Target Stack TLV 
Two new sub-TLV types have been allocated for inclusion within the 
LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1), Reverse-path 
Target FEC Stack TLV (TLV type 16), and Reply Path TLV (TLV type 21). 
o the HSMP-upstream LDP FEC Stack - 29 
o the HSMP-downstream LDP FEC Stack - 30 
The value has been allocated from the "IETF Standards Action" range 
(0-16383) that is used for mandatory and optional sub-TLVs that 
requires a response if not understood. 
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